QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/digital/940099.txt

Internet Message Format | 1994-11-13 | 19KB

Date: Wed,  6 Apr 94 04:30:22 PDT
From: Ham-Digital Mailing List and Newsgroup <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Ham-Digital Digest V94 #99
To: Ham-Digital


Ham-Digital Digest          Wed,  6 Apr 94       Volume 94 : Issue   99

Today's Topics:
                        Baycom TCP/IP Software
                   FTP-able copy of AX.25 standard?
                              GTOR INFO
                      Looking for Wampes docs...
                          MFJ 1270C & Netrom
                     MFJ 1270C TNC and Host Mode
                      Unknown RTTY mode (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 5 Apr 94 11:59:33 GMT
From: ncrgw2.ncr.com!ncrhub2!ciss!wtcp![e-mail]
Subject: Baycom TCP/IP Software
To: [e-mail]

Is there a driver available for TCP/IP on the Baycom software
and modem?

Thanks
--
Bruce Langos
Workstation Products Division F&A
[e-mail]
...!uunet!ncrcom!ciss!wtcp!blangos

------------------------------

Date: 5 Apr 1994 11:38:09 GMT
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!xlink.net!news.urz.uni-heidelberg.de!rz.uni-karlsruhe.de!rzstud1.rz.uni-karlsruhe.de![e-mail]
Subject: FTP-able copy of AX.25 standard?
To: [e-mail]

Johnny B. ([e-mail]) wrote:
: "American Radio Relay League, Inc., AX. 25 Amateur
: Packet-Radio Link-Layer Protocol, Version 2.0,
: October 1984 (or compatible),"

: At any rate, is it around?
You can get it by email from [e-mail]. Send a msg with HELP in the
body of the msg to get information how to use the info-server.
jochen
--
 ##########         Jochen Topf     email: ukkt @ rz.uni-karlsruhe.de
     ##          Schlehenweg 20     ax25 : DH0GAG @ DB0GE.#SAR.DEU.EU
     ####       76149 Karlsruhe
 ##  ##             0721-756508
  ####     <A HREF=http://rzstud1.rz.uni-karlsruhe.de/jt.html>W3-Link</A>

------------------------------

Date: 5 Apr 94 23:28:47 GMT
From: [e-mail]
Subject: GTOR INFO
To: [e-mail]

THE FOLLOWING TEXT WAS PICKED UP FROM THE DL2FAK PACTOR MBX IN GERMANY
BY VE2FK IN MONTREAL. IT WAS WRITTEN BY DL2FAK, ONE OF THE DEVELOPERS
OF PACTOR.

G-TOR - An Improvement?

G-TOR is a new digital mode, which has been developed by Kantronics. Most of
its features (like on-line Huffman data compression, link-quality based baud
rate adjustment, CRC, fundamentals of the packet structure, etc.) are adopted
from PACTOR. The baud rate used in G-TOR can be 100, 200 or 300 baud. The main
differences are the use of Golay forward error correction coding with the ob-
ligatory data interleaving and a hybrid ARQ system.

The Golay encoding however, as used in the G-TOR mode, is only able to correct
3 bits in a block of 24 bits and only half of this block (12 bits) carries in-
formation. The remaining 12 bits have to contain the required redundancy, and
no new data. It is therefore only possible to correct a few errors despite the
large overhead. For this reason the Golay encoding would only be useful for
errors caused by short spikes on the higher short wave frequencies (10 to 20m).
You cannot however expect it to provide any improvements in typical 80m con-
ditions. Here it is necessary not only to use hybrid-2 ARQ systems, but also
suitable, powerful (invertible) codes, which allow the reconstruction of the
original information, even when only the redundancy block is received, rather
than Golay or similar simple block coding, which always requires both blocks
to be received to get the data transferred.

The most robust HF (short wave), narrow band, data transmission systems known,
apply very powerful convolutional codes with Viterbi decoding and soft deci-
sion (requiring an ADC/DSP just like analog Memory-ARQ). The processing speed
of those systems exceeds the capability of a KAM by factor 100. Despite this
very expensive approach, they only achieve around 10 dB better weak signal
performance than PACTOR-1. The closer a system approaches the Shannon boundary
(theoretical throughput limit) the more difficult it gets to gain another one
or two decibels.

W0XI et al claim that they were able to transfer a certain file on the 20m
band in about 5 minutes using G-TOR, whereas PACTOR, which was used afterwards,
took about 20 minutes. The conclusion was that G-TOR would be about 4 times
faster than PACTOR in general, which is actually impossible!! According to the
system description, G-TOR can on average only be about 1.5 times faster than
PACTOR.

The 20m band, which was used for the tests, normally provides a good SNR and
only very few fluctuations. It is therefore obviously no problem to reach
higher throughputs, especially when using 300 baud (even short wave Packet
Radio could have been faster than PACTOR in this case). Also, the comparison
between PACTOR and G-TOR was based on the PACTOR implementation in the KAM,
which does not, apparently, provide the full performance anyway, due to the
different converter and the missing ADC. Since the KAM already uses a modem
designed for 300 baud operation, it is obvious that G-TOR is favoured. The
original PACTOR system will still do better than G-TOR on weak signals, as an
ADC is used in the PACTOR-Controller (PTC) to allow real analog Memory-ARQ.
To achieve impartial results, you have to transfer the same files containing
random characters on the typical 80m conditions in G-TOR using two KAMs and
in PACTOR using two PTCs. The 8.64 characters per second, considered to be the
typical average throughput of PACTOR, and which led to the conclusion that
G-TOR would be 4 times faster than PACTOR, are much slower than the average
rate we obtained with our units. Under even worse conditions we obtained
around 17 characters per second, depending on the transferred information due
to the Huffman coding.

Regardless of the Huffman data compression, which improves the throughput of
both systems in the same way, the comparison of throughput between PACTOR and
G-TOR can be easily calculated. According to the protocol description pub-
lished by W0XI, G-TOR is able to transfer a maximum of 19 characters per se-
cond when running on 200 baud (They claim 69 data bytes in a cycle duration of
2.4 seconds at 300 baud, which means maximum 2/3*69/2.4 characters per second
at 200 baud). The maximum rate of PACTOR at the same speed is 16 chrs/s, which
is a relationship of 1.18 to 1. The Golay encoding is not able to improve the
throughput so dramatically that you finally result in a factor 4. It must be
remembered that the analog Memory-ARQ, as used in the original PACTOR imple-
mentation, is able to improve the effective signal-noise ratio with each ag-
gregated packet and hence enables a higher throughput (especially in weak con-
ditions) than the Golay coding gain. It is therefore obvious that the higher
maximum throughput of G-TOR is mainly based on its higher maximum baudrate.
This however means, it has to exceed the usual 500 Hz band width limit.

With this in mind it must also be remembered that a wider receiver bandwidth
receives more noise. A 300 baud G-TOR signal will therefore have a poorer S/N
ratio than a 200 baud PACTOR signal (if they are both of the same fieldstrength
and the receiver bandwidth is correctly adjusted for both modes). As signals
decrease, G-TOR would have to switch to 200 baud before the PACTOR signal
would be affected, thus further reducing some of the proposed speed gain.

There are still some more disadvantages of G-TOR in comparison to PACTOR, e.g.
the cycle duration is quite long at 2.4 seconds, and will increase to almost 5
seconds when using the Golay encoding, hence leading to quite long break-in
times. The speed adaptation times are necessarily also longer, thus leading to
poorer results in rapidly changing conditions (multipath).

Furthermore, the interleaving and the 3 different baud rates used in G-TOR will
probably lead to a lot of problems with the listen mode, an important point for
all digital modes used in Amateur Radio.

Actually G-TOR is just a modified PACTOR system, which probably does not pro-
vide enough improvement that introducing this mode as another new standard
would be worth-while. With regard to the basic requirements of each digital
data transfer mode (like throughput, bandwidth, error rate, etc.) PACTOR al-
ready represents nearly the optimum attributes that are obtainable with an FSK
system. A real improvement over the current PACTOR system can only be reached
when using different modulation schemes like PSK, which require a DSP hardware.

This step will be done this year with the introduction of PACTOR Level-II.

Tom Rink, DL2FAK

via VE2FK
via W0MFK
via WT0N
ENJOY, I JUST GOT MY GTOR UPGRADE TODAY, IF YOU WANT TO TEST GTOR LET ME
KNOW AND I WILL SET THE AMSAT PBBS ON 30 METERS UP FOR GTOR USE.
YOU CAN CONTACT ME AT
IN [e-mail]
PAC. WT0N@WB0GDB.#STP.MN.USA.NOAM

------------------------------

Date: 5 Apr 94 18:29:34 GMT
From: sdd.hp.com!vixen.cso.uiuc.edu!eagle.sangamon.edu![e-mail]
Subject: Looking for Wampes docs...
To: [e-mail]

Hello,
       I'm looking for any docs on setting up Wampes under Linux.
The docs with the package consist of one skimpy readme file.

Thanks,
Jay

--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Jay Freeman, WT9S           Packet: [e-mail]       +
+                             internet: [e-mail] +
+                             finger for PGP public key.           +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

------------------------------

Date: 5 Apr 94 22:13:33 GMT
From: [e-mail]
Subject: MFJ 1270C & Netrom
To: [e-mail]

> In a previous article, [e-mail] (Chuck Vyverberg) says:
>
> >I saw some messages the last couple fo week giving detailed instructions
> >on how to get the MFJ1270C TNC to run as a netrom node.
> >
>
> To use the MFJ1270C with netrom or TheNET, all you need to do is program
> a 27256 EPROM with the modified firmware module (V2.08B is the one I have
> in three digi's in central IL) and plug it in.  No circuit mods are
> required.
>
> Installing an X1J node is another matter...
>
> 73, Drew
>
> --
> *-----------------------------*-------------------------------------*
> |    Andrew B. White  K9CW    |    internet: [e-mail]    |
> |    ABW Associates, Ltd.     |   phone/fax: [phone]           |
> *-----------------------------*-------------------------------------*

Yes there is a mod required to use the C version of the tnc with TheNet or
X1J. Here's a copy of the message that went around about it.

Bill N8KHN
 [e-mail]


X1/TheNET mods for MFJ-1270C

From: WB0YRQ@NF0N.#NENE.NE.USA.NA
To  : INFO@ALLUS

WB0YRQ @ NF0N.#nene.ne.usa.na /TPK 1.81 Msg #:751  Date:02-01-80
Time:9:56Z

To  modify  the  MFJ-1270C  for  use  with  X1J/Thenet  EPROMS follow
these instructions:

You  must  complete  all  of  these  steps  in order for Netrom firmware
to function.

NOTE:  if  you are not using X1J firmware skip the first step and make
       sure that JP15 is set for 256k.

Step  1:  Bend pin 1 of 27c512 out so it will not touch socket, then
          jumper pin 1 of 27c512 to pin 8 of MODEM header J4. (see X1J docs)

Step  2:  Remove U40. Add jumper from pin 16 to pin 1 (ground pin 16)
                                                    ^
                                        [I think this should be 10 (gnd)]

Step  3:  Remove JMP9 altogether  (no jumper on any pins)

Step  4:  Cut JMPX "PAD" to prevent node from hearing itself

Step  5:  Add 100ohm resistors to R14 and R15 if not already in place.


This information came directly from MFJ and I have used it successfully.
Hope this helps you.
   ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
   3 IMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM; 3
   3 :  [[221100 73's de Al WB0YRQ @ NF0N.#NENE.NE.USA.NA 001122[[  : 3
   3 :  [[221100 Akron, Iowa. 712-568-2810  GRID <EN12RT> 001122[[  : 3
   3 :  [[221100           TCP/IP 44.50.2.6       001122[[  : 3
   3 :  [[221100       Internet: [e-mail]       001122[[  : 3
   3 HMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM< 3
   @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY



------------------------------

Date: 5 Apr 94 22:29:53 GMT
From: sdd.hp.com!saimiri.primate.wisc.edu!news.doit.wisc.edu![e-mail]
Subject: MFJ 1270C TNC and Host Mode
To: [e-mail]

I've been looking through my TNC documentation, and the only reference I find to host mode mentions that documentation is available on diskette, but no command is given for putting the TNC into host mode.

Can anyone help?

73, Tom N9UDL

------------------------------

Date: Tue, 5 Apr 1994 20:05:39 GMT
From: ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!alberta!quartz.ucs.ualberta.ca!kakwa.ucs.ualberta.ca!gov.nt.ca![e-mail]
Subject: Unknown RTTY mode
To: [e-mail]

Keywords: teletype RTTY digital signal identification


In regards to the questions on RTTY signals on the SW bands:
There are hundreds of different FSK modes in use by government and
commercial HF stations worldwide.  95% of these are encrypted so that
they cannot be decoded without the proper key (usually some form of bit
inversion).  In addition to the coded signals, there are also stations
using odd speeds and shifts and stations transmitting non-roman text,
ie, chinese, korean, etc.  If you are interested in decoding some of these
transmissions, Universal Radio makes several high end digital decoders
which can probably decode a large percentage of what is out there.
73
John Boudreau
[e-mail]

------------------------------

Date: Tue, 5 Apr 1994 16:22:10 +0000
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!demon!isis.demon.co.uk![e-mail]
Subject: Unknown RTTY mode
To: [e-mail]

In article <[e-mail]> [e-mail] "James D. Cronin" writes:

>I have also run into these signals.  I always thought the inability
>to decode them was due to shortcomings in hardware interface and
>software.  (I use Hamcom 2.2 with the 741 op-amp interface.)  But
>this may not be the case.
>
>After receiving the last half of a weather-fax map, the station switched
>to RTTY.  It was strong signal, and the weather-fax came in OK.  After
>it switched to RTTY I fired up Hamcom 2.2.  It was easy to figure out
>frequency shift and baud rate with the "Spectrum" and "Bit length"
>screens.  But the text was undeciperable gobbledygook.
>
>Seems like it must be some type of maritime-related station.  Anybody
>have more specific info?

Are you sure that Hamcom isn't just letter shifting ? A lot of weather
related RTTY is almost purely numeric. Most decoders will tend to assume
that they've missed a letter shift and just switch modes after a few
numbers. From then on it is gobbledygook. You can switch off the automatic
shift.

Regards
Ian.
--

  |  Ian Smith            | "The Moving Finger writes;
  |  [e-mail] |  and, having writ, Moves on."

------------------------------

Date: 5 Apr 1994 17:41:22 GMT
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!sunic!psinntp!psinntp!news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com![e-mail]
To: [e-mail]

References <2na50c$[e-mail]>, <2nfdlm$[e-mail]>, <[e-mail]>│î
Reply-To : [e-mail]
Subject : Re: [REPOST] The # in PBBS addresses....

In article <[e-mail]>, [e-mail] (Andy Warner) writes:
|>
|> In article <2nfdlm$[e-mail]>, [e-mail] (Hank Oredson) writes:
|> > [...]
|> > Or is there some magic required of the subdomains of .ampr.org
|> > that is not required of other .org subdomains?
|>
|> Maybe some semblance of responsibility - it sounds like you want
|> to hide an ad hoc network behind a "correctly implemented"
|> (in internet terms) one, without having to to actually change
|> anything. This is a two way street, if you want the "advantages"
|> offered by high connectivity, you may need to change a few things
|> (and - gasp - admit some things were badly thought out, or badly
|> implemented..). Fidonet seem to have grasped that point years ago....
|>
|> Of course, folks can always retreat into the "why would we ever
|> want to connect to anyone else" mindset, the last bastion of
|> people who see their empire crumbling...

This is the third try.

Thus far, the responses have only been "The way it is done now is wrong."
This is from at least three avowed "networking experts."

However, "It is wrong" is useless information.
We all perfectly willing to agree that it is wrong.

I have been attempting to get answers to a different question, let me try it again.

"What should we do so it is done right?"

So far, nobody has posted any useful response to this question.

Can you explain what you meant by "... ad hoc network..." and give examples
of "non-ad hoc networks"?  This might be helpful information.

Long ago and far away (when this packet stuff all started) several of us
asked the same question, and go much the same answers we are getting now:
"No No No, you are DOING IT ALL WRONG".  We got tired of this and simply
went ahead and defined our own subdomains of ampr.org.

Again, we have the same response from the "networking gurus", but a total
lack of useful information.

If indeed "we got it all wrong", what should we do to fix that?

Waiting with 'bated breath for an educational reply ...

   ...  Hank


--

Hank Oredson @ Mentor Graphics
Internet     : [e-mail]
Amateur Radio: [e-mail]

------------------------------

End of Ham-Digital Digest V94 #99
******************************